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Abstract. This paper describes the COINS (COnstraint-based INterac- 
tive Solving) system: a conflict-based constraint solver. It helps under- 
standing inconsistencies, simulates constraint additions and/or retrac- 
tions (without any propagation), determines if a given constraint belongs 
to a conflict and provides diagnosis tools {eg. why variable v cannot take 
value val). coins also uses user- friendly representation of conflicts and 
explanations. 



1 Introduction 

Constraint programming has been proved extremely successful for modelling 
and solving combinatorial search problems appearing in fields such as scheduling 
resource allocation and design. Several languages and systems such as chip Q, 
CHOCO [||, GNuProlog ||], Ilog solver have been developed and widely 
spread. But these systems are helpless when the constraint network to solve has 
no solution. Indeed, only a no solution message is sent to the user who is left 
alone to find : why the problem has no solution; which constraint to relax in 
order to restore the coherence; etc. 

These questions yield two different problems: explaining inconsistency and 
restoring consistency. Several theoretical answers have been provided to address 
those questions: QuickXPlain Q computes conflicts for configuration prob- 
lems, and introduce tools to dynamically remove constraints, PaLM 
uses conflicts to address those issues and deflne new search algorithms, etc. 

User interaction requires user-friendly and interactive tools. In this paper, 
we advocate for the use of k-relevant explanations to provide the COINS 
(COnstraint-based INteractive Solving) system. 

^ In Alexandre Tessier (Ed), proceedings of the 12th International Workshop on Logic 
Programming Environments (WLPE 2002), July 2002, Copenhagen, Denmark. 
Proceedings of WLPE 2002: http://xxx.lanl.gov/html/cs/0207052 (CoRR) 
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COINS helps the user understand inconsistency, simulate constraint additions 
and/or retractions (without any propagation), determine if a given constraint 
belongs to a conflict and provide diagnosis tools {eg. why variable v cannot take 
value val). coins is based upon the use of conflict sets {a.k.a. nogood pO[|), 
explanations and their user- friendly representation p^ . 

This paper is organized as follows: we review the definition and generation of 
conflicts and explanations within constraint programming in section |]. Then, we 
introduce fc-relevance-boimded explanations (section H) and give an illustrative 
example (section Before illustrating the use of fc- relevant explanations in 
the COINS system (section ^) we present a natural way to provide user-friendly 
explanations (section ^) . Finally, we give a short overview of our implementation. 



2 Conflict and explanations for constraint programming 

A Constraint Satisfaction Problem (csp) is defined by a set of variables V = 
{ui, U2, . . . ,Vn}, their respective value domains Di, D2, . . . , Dn and a set of con- 
straints C = {ci, C2, . . . , Cm}- A solution of the CSP is an assignment of values 
to all the variables such that all constraints in C are satisfied. We denote by 
sol{V, C) the set of solutions of the CSP {V, C). 

In the following, we consider variables domains as unary constraints. More- 
over, the classical enumeration mechanism that is used to explore the search 
space is handled as a series of constraints additions (value assignments) and 
retractions (backtracks). Those particular constraints are called decision con- 
straints. This rather unusual consideration allow the easy generalization of the 
concepts that are presented in this paper to any kind of decision constraints (not 
only assignments but also precedence constraints between tasks for scheduling 
problems or splitting constraints in numeric CSP, etc. ). 



2.1 Definitions 

Let us consider a constraints system whose current state {i.e. the original con- 
straint and the set of decisions made so far) is contradictory. A conflict set 
{a.k.a. nogood jl^) is a subset of the current constraints system of the prob- 
lem that, left alone, leads to a contradiction (no feasible solution contains a 
nogood). A conflict divides into two partsQ: a subset of the original set of con- 
straints (C C C in equation |l|) and a subset of decision constraints introduced 
so far in the search (here dci, . . . , dck). 

sol(F, (C'Adci A...Adcfe)) ==0 (1) 

Notice that some special cases may arise. If fc < 1, the considered problem is proved 
as over-constrained. Some constraints need to get relaxed. If C' — ill, the set of 
decisions that has been taken so far is in itself contradictory. This can happen only 
if no propagation is done after a decision has been made. 
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An operational viewpoint of conflict sets can be made explicit by rewriting 
equation ^ the following way: 



C A A dcA ^ ^dcj (2) 




Let us consider dcj : Vj = a in the previous formula. Equation ^ leads to the 
following result {s{v) is the value of variable v in the solution s): 

Vs e sol I C" A I /\ dc, , s{vj) ^ a (3) 
\ Vie[i..fc]\j / / 

The left hand side of the implication in equation || is called an eliminating 
explanation (explanation for short) because it justifies the removal of value a 
from the domain d(v) of variable v. It is noted: expl(v ^ a). 

Explanations can be combined to provide new ones. Let us suppose that 
dci V ... V dcj is the set of all possible choices for a given decision (set of possible 
values, set of possible sequences, etc.). If a set of explanations C[ ~^dci, 
C'j ~^dcj exists, a new conflict can be derived: C( A . . . A Cj. This new conflict 
provides more information than each of the old ones. 

For example, a conflict can be computed from the empty domain of a variable 
V (using explanations for each of the removed values): 

f\ expl{v ^ a) (4) 



2.2 Storing explanations: fc-relevance-bounded learning 

There generally exists several explanations for the removal of a given value. 
Several different approaches were introduced to handle that multiplicity. Depen- 
dency Directed Backtracking records all encountered explanations. The major 
inconvenience of this approach is its exponential space complexity. Indeed, the 
number of recorded explanations increases in a monotonous way. Various algo- 
rithms only keep a single explanation: Dynamic Backtracking and its im- 
provements [MAC-DBT ll^. Generalized Dynamic Backtracking [|l6|. Partial- 
order Dynamic Backtracking |]l7| ) and Conflict- directed BackJumping [p^ . The 
idea is to forget (erase) explanations which are not valid any more considering 
the current set of decision constraints. Space complexity therefore remains poly- 
nomial while ensuring the completeness of the algorithms. Unfortunately, this 
idea is not really compatible with debugging: only one explanation is kept and 
past information are completely lost. 

Instead of recording only one explanation, a more interesting idea is to keep 
information as long as a given criterion is verified: 

— Time-bounded criterion: explanations are forgotten after a given time. This 
criteria is similar to tabu list management in tabu search [T9[. 
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— Size-bounded criterion: pO[ have used a criteria defined in . This criteria 
keeps only the explanations with a size lower or equal to a given value n. 
This criteria limits the spatial complexity, but may forget really interesting 
nogoods. 

— Relevance-bounded criterion: explanations are kept if they are not too far 
from the current set of decision constraints. This concept (called fc-relevance) 
has been introduced in Q and focus explanations/conflict management to 
what is important: relevance wrt the current situation. 

Time and size-bounded recording do have a controllable space complexity. 
This is also the case for /c-relevance learning (c/. section ||). As we shall see, our 
tools are meant for the debugging and the dynamic analysis of programs: the 
space occupation overhead is well worth it. 



3 fc-relevance-bounded explanations 

While solving a constraint problem, the current state of calculus can be described 
with two sets of constraints: R the set of relaxed constraints (decisions that 
have been undone during search, constraints that have been explicitly relaxed by 
the user, etc.) and A the set of active constraints (the current constraint store). 
{A, R) is called a configuration. Following we can now define a fc-relevant 
explanation as: 

Definition 1. k-relevant explanation (^) 

Let {A, R) a configuration. An explanation e is said to be k-relevant if it con- 
tains at most k ~ 1 relaxed constraints, i.e. |e H i?| < k. 

In fc-relevance-bounded learning, only fc-relevant explanations are kept dur- 
ing search. Hence, several different explanations may be kept for a given value 
removal. Thus expl{v ^ a) will not contain any more a single explanation but 
the set of fc-relevant explanations recorded for the removal of value a from the 
domain d{v) of variable v. 



3.1 Managing fe-relevant explanations 

Computing fc-relevant explanations fc-relevant explanations, as regular ex- 
planations can be computed during propagation. However, some issues arise 
(see example |l|) . 

Example 1. (Example for explanation computation) 

Let us consider two variables vi and V2. Let us assume that value a from v\ 
is only supported by value b from V2 in constraint c. Let finally assume that b 
is removed from V2 (a set of explanations being: {{ci, C2}, {ci, C3}, {c4, cs}}). 
This removal needs to be propagated. 

But, which explanation one should choose to compute the explanation of the 
value removal di 7^ a ? Do we have to consider all the possibilities {c, ci,C2}, 
{c, cijCa} or {c, €4,05}? Only one ? 
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As values are removed only once, we can focus on one particular explanation: 
the first one. The explanation computed at removal time is called the main one. 
That explanation will be used to compute forthcoming explanations. Moreover, 
this explanation is exactly the one that would have been computed by a classical 
approach (see section [2.lD . 

Example (followed) 

Let us suppose that the main explanation for the removal of value b from «2 

is {ci,C2}. 

Thus, the removal vi ^ a will be justified by {c, ci,C2}. 

Evolution of the fc-relevant explanations We need to maintain the rel- 
evance information attached to stored explanations upon constraint additions 
and retractions. In both ways, the relevance of explanations may vary. The idea 
is to keep track of these variations and to forget explanations as soon as they 
become irrelevant. We organize the contents of the /c-relevant explanations ac- 
cording to the relevance of its explanations. More precisely, all fc-relevant ex- 
planations for a given removal expl{v ^ a) are partitioned into k subsets, i.e. 
expl{v a) = Uig[o../c_i]ea;pZ(u ^ a,i). Subset expl{v ^ a,i) contains the expla- 
nations having i relaxed constraints. 

Example 2. (Updating 2-relevant explanations) 

Consider example |l|. We assume that no other explanation has been found 
for the removal vi 7^ a. The 2-reIevant explanations for this removal are : 
expl{vi ^ o, 0) = {{c, ci,C2}, {c2, C4}}, expl{vi 7^ a, 1) = {{01,03}, {c2, C3}}. 
Notice that constraint C3 is relaxed. That is why both {01,03} and {02,03} are 
in the expl{vi / a, 1). 

— If constraint ci is relaxed: explanation {c, ci,C2} jumps from expl{vi 7^ 
a, 0) to expl{vi 7^ a, 1); explanation {ci, C3} is forgotten and thus removed 
from expl{vi 7^ a, 1) (we have k = 2). The new set of 2-relevant ex- 
planations is therefore: expl{vi 7^ a, 0) — {{c2,C4}}, expl(v\ 7^ a, 1) = 

{{C, Ox, 02}, {C2,C3}}. 

— If constraint C3 is reactivated (from the original set of explanations) : expla- 
nations {ci, C3} and {c2, C3} become valid and the new set of 2-relevant ex- 
planations is therefore: expl{vi ^ a,0) — {{0, ci, C2}, {c2, C4}, {ci, 03}, {£2,03}}, 
expl{v\ 7^ a, 1) = {}. 

Computing conflicts The same dilemma that we encountered when comput- 
ing explanations appears when computing conflicts. Indeed, when a contradiction 
is identified (a domain of a variable becomes empty), we saw that equation ^ 
computes a conflict. However, there may exist several explanations for each con- 
sidered value removal. Contrarily to the explanation computation process, we 
chose here to provide all possible explanations (limiting ourselves to valid expla- 
nations i.e. expl(v 7^ a, 0)) for all i € [0..fc — I]. The resulting number of valid 
conflicts is: 

Y[ \expl{v a,Q)\ conflicts (5) 
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Example 3. (The possible nogoods) 

Let us consider example |^ but with a different k. We assume that values a and 
h from v\ are have been removed with the following explanations: expl{v\ 7^ 
a, 0) = {{c, ci, C2}, {c2, C4}} and expl(vi / 6, 0) = {{ci, C5}, {02,05}}. 
Applying equation H leads to the following nogoods; 

- {c, ci, C2} U {ci, C5} 

- {c, Ci, C2} U {C2, C5} 

- {C2,C4} U {cijCs} 

- {C2,C4} U {C2,Cs} 

Here, the main explanation for ui 7^ a is {c, ci, C2} and {ci, C5} is the one for 
vi / 6. 



3.2 1-relevance vs. classical approaches 

All classical approaches {Dynamic Backtracking or MAC-DBT) forget expla- 
nations as they become invalid. A 1-relevant learning technique will obviously 
proceed the same way. However, it differs from classical approaches by the num- 
ber of recorded explanations by removal. Indeed, during resolution, one may 
come across an explanation for an already performed removal. Instead of not 
taking it into account, 1-relevance will keep that secondary information^. 

Furthermore, all classical approaches take into account only one conflict. This 
conflict is computed following to equation^. Our approach may deal with a set of 
conflicts (see equation]^). Nevertheless that particular explanation management 
has a computational and spatial cost. 



3.3 Complexity issues 

To compute the complexity of our approach, let us consider a CSP defined upon 

n discrete variables with maximum domain size d upon which are posted e 

constraints. If wc only keep a single explanation per value removal, there will be 

at most n X d explanations of maximal size e + n i.e. all the constraints from 

the problem (e) and the decision constraints (n). Thus the complexity of the 

classical approach is 0((e + n) x n x d). 

However, as far as the fc-relevance approach is concerned, an explanation can 

contain up to fc — 1 relaxed constraints, the maximal size of an explanation being 

n + e + k— 1. The maximum number of explanations for a given value removal is 

bounded by the maximum number of non included subsets in a set. The worst 

/ e-|-n-|-fc — l \ . r - / 7 -,\/,^ 

case is: / , t \ /o 1 subsets of size (e + n + fc — l)/2. 



{e + n + k- l)/2^ 

Therefore, the spatial complexity for storing fc-relevance explanations is in: 

ofnxdx ( , X (e + n + k-l)/2 

\ \{e + n + k-l)/2 J ^ ^ ^ " 



5 



It will be used to compute conflict. The main explanation will still be the only used 
to compute subsequent explanations. 
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4 An example : the conference problem 

To illustrate the use of the /c-relevant explanations, we present the resolution of 
the conference problem 1 22 . From now on, we fill focus our study to 1-relevance. 



4.1 Presentation of the problem 

Michael, Peter and Alan are organizing a two-day seminar for writing a report 
on their work. In order to be efficient, Peter and Alan need to present their work 
to Michael and Michael needs to present his work to Alan and Peter (actually 
Peter and Alan work in the same lab). Those presentations are scheduled for a 
whole half-day each. Michael wants to known what Peter and Alan have done 
before presenting his own work. Moreover, Michael would prefer not to come the 
afternoon of the second day because he has got a very long ride home. Finally, 
Michael would really prefer not to present his work to Peter and Alan at the 
same time. 



4.2 A constraint model for the conference problem 

A constraint model for that problem is described as follows : let Ma, Mp, Am, Pm 
the variables representing four presentations {M and m are respectively for 
Michael as a speaker and as an auditor). There domain will be [1,2,3,4] (1 
is for the morning of the first day and 4 for the afternoon of the second day). 
Several constraints are contained in the problem: implicit constraints regarding 
the organization of presentations and the constraints expressed by Michael. 
The implicit constraints can be stated: 

— A speaker cannot be an auditor in the same half-day. This constraint is 
modelled as: ci : Ma ^ Am, ci : Mp ^ Pm, C3 : Ma 7^ Pm and C4 : Mp ^ 
Am. 

— No one can attend two presentations at the same time. This is modelled as 
C5 : Am ^ Pm. 

Michael constraints can be modelled: 

— Michael wants to speak after Peter and Alan: cg : Ma> Am, cj : Ma > Pm, 
C8 : Mp > Am and cg : Mp > Pm. 

— Michael does not want to come on the fourth half-day: cio : Ma ^ 4, cn : 
Mp ^ 4, C12 : Am ^ 4 and C13 : Pm ^ 4. 

— Michael does not want to present to Peter and Alan at the same time: C14 : 
Ma ^ Mp. 



4.3 Using classical approaches 

Table |l] shows the resulting explanations for both approaches (classical and 1- 
relevant) after adding constraints from C\ to Cg. The column associated to the 
classical approach contains only a single explanation by removal, opposed to the 
1-relevant column. The domain of the variable Pm is empty. We deduce that our 
problem is over-constrained. According to the equation ^ of the section ||, we 
obtain the conflict {Ci, C2, C3, C4, C5, Cg}. 
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Variable Value 


Explanation 


1-relevance 


present ? 


p 


i 


{Ci, C2, C4, Ce} {Ci, C2, C4, Ce}, {Ci, C4, Ce} 


no 


p 


o 
z 




IO5, Oej 


no 


p 


Q 

o 


IO5, 06 1 


{O5, Oej 


no 


p 

J m 


4 






no 


/i 


i 








yes 


Am 


2 


{C4, Ce} 


{C4,Ce} 




Am 


3 


{C4, Ce} 


{C4,Ce} 


no 


Am 


4 


{C2} 


{C2},{C4},{C4,Ce} 


no 


Mp 


1 


{C4} 


{C4},{C5},{Ce} 


no 


Mp 


2 








yes 


Mp 


3 


{Ce} 


{Ce} 


no 


Mp 


4 


{Ce} 


{Ce} 


no 


Ma 


1 


{C2} 


{C2},{C,} 


no 


Ma 


2 








yes 


Ma 


3 








yes 


Ma 


4 








yes 



Table 1. Domains after the introduction of constraints 



4.4 Solving using 1-relevant explanations 

Table || presents the 1-relevant explanations associated to every removal after we 
have removed the redundant explanations like {Cq^Cq} for the removal Pm 7^ 
4. But as the second approach proposes several explanations, we can deduce 
several conflicts. In our case, we obtain two conflicts : (Ci, C3, C4, C5, Cg} and 
jCi, C4, C5, Ce}. 

The second conflict is more precise since it is included in the first one. There is 
a quite important difference between the conflict provided by the first approach 
which contains all the constraints that do not help the user and the conflicts 
provided by the 1-relevant approach. 

4.5 User interaction 

As we can see in our example, conflicts and explanations are sets of low-level 
constraints. Only a specialist can understand and correctly interpret the pro- 
vided information. In order to design user interaction tools, we therefore need 
to provide translation tools to make accessible to any user the low-level con- 
straints. In the next section, we introduce user-friendly explanations to address 
that issue. 



5 User-friendly explanations 

In this section, we introduce the notion of user-friendly explanations We 
provide a set of tools to address the accessibility issue of conflicts and explana- 
tions made of low-level constraints. 
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Variable Value 


Explanation 


1-relevance 


present ? 


-1 771 


1 


/ \ 
iOi, O2, 04, Oe} 


•[Oi, 04, Osl 


no 


m 


o 
z 


•[O5, Oel 


•[O5, 06| 


no 


p 

J m 


o 
O 


/ He: \ 


/ ^^^^ \ 

•[O5, 06/ 


no 


p 

m 


/I 

4 




ioal, iOsi 


no 




1 


(J 




yes 


-^m 


2 


\04, 06/ 


\04, 06/ 




-^m 


3 


{C4, Cfi\ 


{C4, C6} 


no 


-Am 


4 




{C^2},{C4} 


no 


Mp 


1 




{C4},{C5},{C6} 


no 


Mp 


2 








yes 


Mp 


3 


{C6} 


{^6} 


no 


Mp 


4 


{C6} 




no 


Ma 


1 


{C2} 


{C2},{C3} 


no 


Ma 


2 








yes 


Ma 


3 








yes 


Ma 


4 








yes 



Table 2. Final set of explanations 



A solution to that issue will be obtained thanks to the developer of the 
application. When developing an application, such an expert needs to translate 
the problem from the high level representation (the user's comprehension of the 
problem) to the low- level representation (the actual constraints in the system). 
We note this translation a user system translation. 

For user-friendly explanations, we need the other way translation: from the 
low-level constraints (solver adapted) to the user comprehensible constraints 
(higher level of abstraction). We note this translation a system — > user trans- 
lation. That translation is usually not explicitly coded in the system. Asking a 
developer to provide such a translator while coding would be quite strange for 
him. We chose to automatize that translation in a transparent way. 



5.1 Hierarchical representation of problems 

This idea relies on a single hypothesis: all aspects of a constraint-based appli- 
cation can be represented in a hierarchical way. Indeed, any object appearing 
in a constraint problem is attached to at most a single /at/ier-object. Note that 
a given /ai/ier-object may have several c/ii^dren-objects. For exa mpl e, figure ^ 
gives a graphical representation of the problem defined in section 4.1. 



5.2 Building a system — > user translator 

While developing a constraint application, the user only needs to explicitly state 
the underlying hierarchy of his problem. Only the leaves of this structure, namely 
the low-level constraints, can be used by the constraint solver. 
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The conference problem 



Implicit cr>nstra n^E 



No auditor for t-vo 
pres. at ttig sama time 



Speaker Auditor 
inconsislendea 



MichsEl ccjnElraints 



Pet^rancl Alan atth^i 
Si5m^i tirmfj 



No f>resentatkins on 
the r halMay 



Peitar and Alan befora 
Michaels prasentaton 



i i i 



"I 1 



12] El rcTi c;,r II c.,1 icTii c„ iicTi 



Fig. 1. An hierarchical view of the conference problem 



The leaves may be too low-level for a typical user of the final application. 
However, he can understand higher levels in the hierarchy. What allows the hi- 
erarchy hypothesis is to build with no effort for the developer a hierarchical 
representation of the problem. Once built, this representation can be used to 
interact with any user through user-friendly explanations. Such explanations are 
provided using procedures converting low-level constraints into user understand- 
able pieces of the hierarchy. Those procedures are completely problem indepen- 
dent and may be provided within the constraint solver. 

The user perception of a given problem can be seen as a cut in the hi- 
erarchical view of the considered problem. For example, let suppose that the 
user is Michael who does not want to deal with implicit constraints. Although 
he does understand his own wishes. Therefore, his view of the problem would be: 



The conf. problem 



P&A before 



Not 4*^ 1/2 day 



and P&A not same time 



Our example has no solution, one explanation for that situation provided by 
a classical approach is: {ci, C2, C3, C4, C5, ce}. 

Michael looks at the explanation from his point of view. We therefore need to 
project the concrete explanation onto his representation. The projection consists 
in projecting the constraints {ci, C2, C3, C4, C5, cq} from bottom to the top of the 
hierarchy representing the problem (see figure ^ until a user understandable 
box is reached. 

For example, the projection of the constraints {ci, C2, C3, C4} gives in first step 
the Speaker vs. Auditor box. Unfortunately, this box is not understandable by 



Michael. In this case, the projection continues to the father box: Implicit constraints 
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Once again, this box is not understandable by Michael and the projection gets to 


The conf. problem 


. Finally, we reached 


The conf. problem 


box which Michael 


can deal with. The projection of C5 gives the same box through 


Auditor vs. 2 pers. 



and 



box is user understandable. 



Implicit constraints . For cg, the projection is easier because the first reached 

and 



The final projection gives: The conf. problem 



P&A before 



He can 

ask to discard one box. For example, the box Michael wants to speak after Peter 
and Alan. 



6 Exploiting fc-relevant explanations 

fc-relevance provides more interesting explanations and allows to obtain a better 
diagnosis. In this section, we present five concrete situations which the user is 
frequently confronted in the case of a failure. We show how fc-relevant expla- 
nations allow to better understand and to analyze this failure and to quickly 
simulate various scenarios. 



6.1 Giving more precise explanations 

If we have two explanations for the same removal ei and 62 such as ei C 62, 
then we know that the constraints which belong to 62 \ ei are not responsible 
for the removal. We say that ei is more precise than 62. 

Consequently, constraints belonging to 62 — ei are not responsible of the 
incoherence if they do not appear in the other removals, fc-relevance is, of course, 
not the panacea (see constraint Cq which is not responsible for the removal 
P„i ^ 4 but intervenes in the removal Pm ^ 1 - it appears in the conflict). But, 
the multiplicity of explanations leads to more precise explanations and conflicts. 

6.2 Does a constraint belong to a conflict? 

An interesting issue when debugging is to know wether a given constraint belongs 
to a conflict or not. fc-relevant explanations help answering that question. 

Let suppose that the cause of incoherence is the variable Am (see table §). 
As there is a failure (the domain of variable Am is empty), the user wants to 
know if constraint C5 belongs to a conflict by referring to the table |[ Based 
on the classical approach, the only conflict will be {C2, C3, 6*4,(76}. Indeed, The 
answer will be negative (C5 ^ {C2, C3, C4, Ce}). While our 1-relevant approach 
provides 8 conflicts and indicates that the constraint C5 is strongly responsible 
of the incoherence. 



6.3 Simulating constraint relaxation 

Determining if a given constraint belongs to a conflict or not may lead to spend 
a lot of time by relaxing each suspected constraint. For that reason, we propose 
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Variable Value Explanation 1-relevance not deleted ? 

i {c^} {ChYJch} ^ 

A™ 2 {C4,C6} {C4,C6},{C5} no 
A™ 3 {C4,C6} {C4,C6},{C5} no 
A„ 4 {Ca} {C'2},{C4} no 

Table 3. New state of the variable Am 



a tool which allows to simulate a relaxation (without any propagation) only by 
updating the fc-relevant explanations. 

For example, let suppose that the user suspects t hat constraint C3 belongs to 
a conflict. The constraint-checking tool (see section |6!^ ) confirms it. The relax- 
ation of this constraint will put back all the values a such as C3 £ expl{A„i ^ a). 
According to table ||, the constraint C3 is partly responsible for the removal 
Am ^ 1. The classical approach would have put back the value 1 in the domain 
of Am and launched the propagation phase. Unfortunately, the problem is always 
over-constrained because the removal Am 7^ 1 is justified by the constraint C5 
and the domain of Am becomes empty again. 

1-relevant explanations allow us to know that the relaxation of the constraint 
C3 will lead towards an another failure due to the removal Am 7^ 1 that will be 
justified by another explanation: {C5}. Thus, our tool is able to indicate to the 
user if a relaxation of a suspected constraint will lead to another immediate 
failure. 

6.4 Simulating constraint addition 

To solve a dynamic problem, a simple execution from scratch is too expensive for 
every modification introduced by the user. Some proposed tools allowing to solve 
the problem from the current solution do not allow to know if this modification 
(precisely the addition of a previously relaxed constraint) will lead towards a 
failure. 

It is helpful to take advantage of the information accumulated during the 
resolution of the previous problem to avoid adding constraints leading towards 
an immediate failure. For this reason, we have proposed a tool simulating the re- 
introduction of a relaxed constraint without any propagation. This tool informs 
the user if the addition of a relaxed constraint leads towards a failure or not. So 
we can avoid reintroducing such constraints. 

For example, let suppose now that the user has removed constraints {03, C5} 
to put back value I in the domain of Am- The new domains (along with the as- 
sociated explanations) are reported in table |[ Let suppose that our user wants 
to put back the previously relaxed constraint C3. A naive approach consists in 
propagating the constraint from the current situation (it leads to a contradic- 
tion). However, 2-relevant explanations can be used to simulate this constraint 
addition by updating the relevance status of associated explanations. Some of 
them may become valid ({03} in our example) and therefore remove some values 
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(1 from Am here). Here, with no propagation at aU, using /c-relevant explanation 
could have helped the user by telling him that adding constraint C3 would have 
lead to a contradiction. 



Tab 



Variable Value Explanation 1-relevance 2-relevance present ? 



Am 1 {C3},{C5} yes 

A„ 2 {C4,C6} {Ci,Ce},{Cs} no 

Arr, 3 {C4,C6} {C4 , Cg} , {C5 } UO 

Am 4 {C2} {C2},{C4} no 



e 4. New state of the variable Am after relaxation of C3 and C5 



6.5 Providing error diagnosis 

Imagine now that after some relaxations, the user wants to know why the vari- 
able Mp cannot take the value 1? The classical approach provides the expla- 
nation {Ce}. While the 1-relevant approach provides the set of explanations: 

{{C4},{C5},{C6}}. 

We notice that 1-relevance provides a richer diagnosis than the classical ap- 
proach. 



7 Implementation 

COINS has been implemented in choco^ using the PaLM system j^. choco 
allows : to propagate the constraints, to manage domains as well as other filter- 
ing algorithms, local search, etc. Experiments show that when k increases, the 
performance of fc-relevance decreases. In the other hand, for fc = 1 and fc = 2, we 
obtain the same temporal performances as mac-dbt[^. For fc = 1 and k — 2, 
the time lost to manage the fc-relevant explanations is compensated by avoiding 
future failures. For fc > 3, fc-relevance loses its advantages. More precisely, for 
such a fc, we are losing time managing explanations that will seldom let us avoid 
future failures. Especially, we shall update explanations which will never become 
valid (i.e. 1-relevant). 

® choco is an open source constraint engine developed as the kernel of the OCRE 
project. The OCRE project (its name standing for Outil Contraintes pour la 
Recherche et I'Enseigneraent, i.e. , Constraint tool for Research and Education) aims 
at building free Constraint Programming tools that anyone in the Constraint Pro- 
gramming and Constraint Reasoning community can use. For more information see 
www.choco-constraints.net. 
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8 Conclusion 

In this paper, we have introduced the foundations of several interactive tools 
which are of great help for a user to solve an over-constrained problem. We 
have shown the effectiveness of these fc-relevance-based tools, fc-relevance keeps 
several explanations by removal and forgets them once they become irrelevant. 

We have shown the contribution of our /c-relevance-based tools compared to 
classical approach, fc-relevance provides more precise explanations; gives some 
general information that cannot be accessible within a classical framework: fc- 
relevance allows the simulating of constraint retraction/addition and so provides 
richer diagnosis tools. 

Our current work includes designing algorithms which compute the best con- 
flict from all the explanations. We investigate adding user-based comparators 
[ p3| to our tools in order to provide automatic comparison of solutions. Also, we 
try to decrease the space complexity by managing differently the explanations. 
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